2018 年 3 月 16 日

摘要： EOS.IO 软件引入了一种新的区块链架构，旨在实现去中心化应用的垂直和水平扩展。这种拓展的实现方法是通过创建一个类操作系统的底层软件，然后在此基础上构建应用程序。该软件提供帐户，身份验证，数据库，异步通信以及跨CPU或群集的应用程序调度。此技术的最终目标是实现每秒百万次交易，用户免费使用，并且可以在在受治理的区块链环境中快速且轻松地部署和维护去中心化应用程序的区块链架构。

请注意：本白皮书中引用的密码学 TOKENS 指代的是那些已发布且使用 EOS.IO 软件的区块链。这些 Tokens 并不指代那些在 ETHERUM 区块链中分发的与 EOS TOKEN 相关的兼容 ERC-20 标准的 TOKENS。

版权所有 ©2018 block.one

在引用原始来源和适用的版权声明的前提下，对于非商业或以教育为目的(即不收取费用或非商业目的)的情况中, 任何人可以无需许可地使用，复制或分发本白皮书中的所有内容。

**免责声明：本 EOS.IO 技术白皮书 v2 仅供参考。block.one 不保证本白皮书的准确性或得出的结论，本白皮书“按原样”提供。在此白皮书中，block.one 没有作出任何具有明示，暗示，法令或其他形式的陈述和保证并且明确表示不承担任何与此相关的责任，包括但不限于：（i）适销性保证，适用于特定用途，适用性，用途，所有权，未侵权; （ii）本白皮书的内容没有错误; （iii）此类内容不会侵犯第三方权利。 block.one 及其附属公司对因使用，参考或依赖本白皮书或任何包含本白皮书内容而引起的任何损害不承担任何责任，同样也不负有告知相关者可能危害的责任。在任何情况下，block.one 或其关联公司均不对任何个人或实体承担任何直接或间接，后果性，补偿性，偶然性，实际性，示范性，惩罚性或特殊性的任何损害，损失，责任，成本或费用，以及因使用或参考或依赖本白皮书或包含此白皮书的任何内容而导致的包括但不限于任何业务，收入，利润，数据，使用，商誉或其他无形的损失。

背景

区块链技术于 2008 随着比特币的推出而为人所知，从那时起企业家和开发者就试图推广该技术以便在单一区块链平台上支持更广泛的应用。

虽然许多区块链平台一直在努力支持功能性的去中心化应用，但是某些基于特定应用的区块链却率先达到了每天千万的活跃用户量(如 BitShares 的去中心化交易(2014)和 Steem 社交平台(2016))，这些成功的区块链应用通过将性能提高到每秒数千个事务，延迟减少到 1.5 秒，消除每笔交易费用，并提供类似于现有中心化应用的用户体验从而达到如此之高的用户活跃度。

现有的区块链平台因为高昂的手续费以及有限的计算能力而无法被广泛使用。

区块链应用程序的要求

为了获得广泛使用，区块链上的应用程序需要一个足够灵活的平台来满足以下要求：

支持百万级别的用户量

想要与 eBay，Uber，AirBnB 和 Facebook 等企业竞争，那么相应的区块链技术就需要需要能够处理千万级别的日活跃用户数。除非达到平台可承受用户数上限的特殊情况，否则应用程序需要能够保持正常地运行，因此一个支持大规模用户数的平台是至关重要的。

免费使用

应用程序开发人员需要能够为用户提供免费服务的灵活性; 用户不应该因为使用平台或从平台服务中受益而付费。可供用户免费使用的区块链平台更有可能会获得广泛的使用。当被广泛使用之后，开发人员和企业可以制定有效的营收策略。

易升级和易修复

构建基于区块链应用程序的企业需要能够为他们的应用添加新功能的灵活性。因此平台必须支持软件和智能合约升级。

一般而言, 绝大多数的软件都会受到 Bug 的影响，即使是使用了最严格的形式验证的软件也不例外。平台必须足够强健以便在不可避免的错误发生时可以及时修复。

低延迟

良好的用户体验要求应用能够在数秒内就给出可靠的反馈。反馈的时间越长就越容易令用户感到沮丧，并使基于区块链的应用程序难以与其所对标的非区块链方案竞争。因此平台应该支持低延迟的事务。

高顺序执行性能

有些应用程序各步骤之间的结果相互依赖，因此无法通过并行算法进行处理。如交易所之类的应用程序需要足够的顺序性能来处理大量数据。因此，平台应该拥有高效的顺序性能。

并行性能

大规模应用程序需要在多个 CPU 和计算机之间划分工作负载。

共识算法(BFT-DPOS)

EOS.IO 软件使用了唯一已知的能够满足区块链应用程序性能要求分的布式一致算法 - 委托证明(DPOS)。基于该算法，那些在基于 EOS.IO 软件的区块链上持有 Token 的人可以通过连续批准投票系统选择出区块生产者。任何人都可以参与区块生产，只要他们能够说服 Token 持有者为他们投票, 他们就有机会生产区块。

EOS.IO 软件可以确保每 0.5 秒生成一个区块，并且只有一个生产者可以在任何给定的时间点生成区块。如果在预定时间没有产生区块，则该时间段的区块将被跳过。当跳过一个或多个区块时，区块链中存在 0.5s 或更多的时间段。

使用 EOS.IO 软件，区块将在 126 轮内被生成(每组 6 个块，共21个生产者)。在每轮开始时，将根据 Token 持有者的投票结果选择 21 个独特的区块生产者。选定的生产者按照由 15 个或更多区块生产者商定的顺序进行安排。

如果区块生产者错过了一个区块并且在过去 24 小时内没有产生任何区块，则直到他们通知区块链他们打算再次开始生产区块，否则他们将被区块链忽略。通过最大限度减少被证明是不可靠的区块生产者导致的缺失区块可以确保网络平稳运行。

在正常情况下，DPOS 区块链不会发生任何分叉，因为区块生产者以合作而不是竞争的方式生产区块。如果出现分叉，共识机制将自动切换到最长链。因为区块添加到区块链分支的速率与使用相同共识机制的区块生成者的数量成正比，所以此方法是有效的。换句话说，因为具有更多生产者的分叉经历缺失更少，所以具有更多生产者的区块链分支的长度将比具有较少生产者的分叉的增长更快。

此外，一个区块生产者不会同时在两个分叉上产生区块。如果有区块生产者被发现这样做了，他就会被投票出局。这种重复生产的密码学证据也可用于自动删除滥用者。

通过允许所有生产者对所有区块进行签名，只要没有生产者使用相同时间戳或在相同的块高度签署两个区块，拜占庭容错算法就可以被添加到传统 DPOS 算法中。一旦 15 个区块生产者签署了一个区块，该区块就被视为是不可逆转的。任何执行非法操作的拜占庭生产者都会因签署具了有相同时间戳或块高度的两个区块来而留下密码学证据。在这种模式下，不可逆转的共识能在 1 秒内实现。

交易确认

典型的 DPOS 区块链中, 所有的区块生产者都会参与其中。一个交易平均可以在广播时间 0.25s 后被 99.9% 的确认。除了 DPOS 之外，EOS.IO 还增加了异步拜占庭容错(aBFT)，以便实现更快地实现不可逆性。aBFT 算法能在 1s 内提供 100% 的不可逆性确认。

交易委托证明(TaPoS)

EOS.IO 软件要求每个事务都包含最近区块头的部分哈希值。要求此哈希有两个目的:

1. 防止在不包括引用区块的分支上重放事务;
2. 告知区块网络某一特定用户及其资产处在特定分支上;

随着时间的推移，所有用户最终都会直接确认区块链，因为伪造链无法从合法链中迁移交易使得链的伪造很难实现。

账户

EOS.IO 软件允许所有帐户使用长度最多为 12 个字符的链内唯一的可读名称进行引用。该名称由帐户的创建者选择。帐户创建者必须保留存储新帐户所需的内存，直到新帐户拥有足够在内存中保留自己所需的 Token 。

在分布式的环境中，应用程序开发人员将承担注册新账户的费用。传统企业已经以广告，免费服务等形式为每个客户花费了大量资金。相比之下，为新的区块链账户提供创建账户的资金成本是微不足道的。幸运的是，在其他应用中创建过帐户的用户不需要再次创建。

操作和处理脚本

每个帐户都可以将结构化操作发送给其他帐户，并可以定义脚本以便在收到操作时进行处理。EOS.IO 软件为每个帐户提供了只能由自己的操作处理脚本访问的私有数据库。操作处理脚本还可以将操作发送到其他帐户。操作和自动处理操作的脚本的组合便是在 EOS.IO 定义智能合约的方式。

为了支持并行执行，每个帐户还可以在其数据库中定义任意数量的范围。区块生成者将以对内存访问范围没有冲突的方式调度事务，因此区块生成者可以并行执行操作。

基于角色的权限管理

权限管理涉及确定一个操作是否得到适当授权。最简单的权限管理形式是检查事务是否具有所需的签名，但这意味着已经知道所需的签名是什么。一般而言，权力受个人或群体的约束，并且经常被划分。EOS.IO 软件提供了一个声明性的权限管理系统，该系统可以为谁可以做什么以及何时可以做做出细粒度和高级别的控制。

将身份验证和权限管理标准化并与应用程序的业务逻辑分离至关重要。这使得开发能够以通用方式管理权限的工具成为可能，并且还为性能优化提供了重要的机会。

每个帐户可以由其他帐户和私钥的任何加权组合进行控制。这创建了一个分层权限结构，反映了权限在现实中的组织方式，使得多用户对帐户的控制变得前所未有的简单。多用户控制是对安全性的最大贡献者，如果使用得当，它可以大大降低因黑客攻击而导致的失窃风险。

EOS.IO 软件允许帐户定义密钥和/或帐户的哪些组合可以将特定的操作类型发送到另一个帐户。例如，可以为用户的社交媒体帐户设置一个密钥同时为访问交易所账户设置另一个密钥。甚至可以无需为其他账户分配密钥的情况下授予其他帐户代表用户帐户行事的权力。

命名权限级别

使用 EOS.IO 软件，帐户可以定义命名权限级别，每个级别都可以从更高级别的命名权限中派生出来。每个命名权限级别定义一个权限; 权限是一个阈值多签名检查，由其他帐户的密钥/命名权限级别组成。例如，帐户的 “朋友” 权限级别可以设置为该帐户上的一个允许任何该账户的朋友进行的操作。

另一个例子是 Steem 区块链，它有三个硬编码的命名权限级别：owner，active 和 posting。posting 权限只能执行投票和发布等社交操作，而 active 权限可以执行除更改所有者之外的所有操作。owner 权限用于 cold-storage，并且能够执行所有操作。EOS.IO 软件通过允许每个帐户持有者定义他们自己的权限层次结构以及操作分组来实现命名权限级别。

权限映射

EOS.IO 软件允许每个帐户定义合约/操作或其他账户/其他账户命名权限级别之间的映射。例如，帐户持有者可以将帐户持有者的社交媒体应用程序映射到帐户持有者的“朋友”权限组之中。通过此映射，该账户的任何朋友都能够以该账户的名义在其社交媒体上发布消息。即使他们将作为帐户持有人发布消息，他们仍然会使用自己的密钥来签署操作。这意味着始终可以识别哪些朋友以何种方式使用了该帐户。

权限评估

当**@alice为@bob提供了类型为“Action”的操作时，EOS.IO 软件将首先检查@alice是否已经对@bob.groupa.subgroup.Action定义了权限映射。如果没有找到任何结果，软件将继续检查@alice是否定义了@bob.groupa.subgroup和@bob.groupa的映射，最后检查是否定义了@bob的映射。如果仍未找到匹配的映射，则假定的映射是权限组@alice.active**。

一旦识别出映射，则使用阈值多签名检查和与命名权限相关联的权限来验证签名授权。如果失败，则它将遍历父级权限直到 owner 权限**@alice.owner**。

默认权限组

EOS.IO 技术还允许所有帐户拥有可以执行所有操作的 "owner" 权限组，以及可以执行除更改所有者权限组之外的所有操作的 "active" 组。所有其他权限组都派生自 "active" 组。

权限的并行评估

权限评估过程是“只读”的，并且对事务所做的权限的更改在区块结束之前不会生效。这意味着可以并行执行所有事务的密钥和权限评估。此外，这还意味有可能在不启用需要回滚的昂贵的应用程序逻辑的情况下快速验证权限。最后，这意味着可以在收到待处理事务时评估事务权限，并且在应用它们时不需要重新评估事务权限。

考虑到所有因素，权限验证占据了交易验证所需计算量的很大比例。将其设置为只读且可并行化可以显着提高性能。

重放区块链以从便操作日志中重新生成确定性状态时，无需再次评估权限。包含在已知是良好的区块中的事务可以跳过此步骤。这大大减少了重放不断增长的区块链所带来的计算负担。

强制性延迟

操作时间是安全的关键组成部分。在大多数情况下，在私钥在使用之前，无法知道私钥是否被盗。当人们使用要求将密钥保存在连接到互联网中的电脑的应用时，基于时间的安全性尤其重要。EOS.IO 软件使应用程序开发人员能够指示某些操作在包含在区块中之后必须等待某一最短时间后才能发挥作用。在等待期间，这些操作可以被取消。

之后，当其中一个操作被广播时，用户会收到电子邮件或文本消息的通知。如果他们没有对其进行授权，那么他们可以使用帐户恢复流程来恢复其帐户并撤消操作。

所需的延迟取决于操作的敏感程度。支付咖啡可能没有延迟，并且在几秒钟内不可逆转，而买房可能需要72小时的清算期。将整个帐户转为新控制可能最多需要30天。最终的延迟由应用程序开发人员和用户选择得出。

恢复被盗钥匙

EOS.IO 软件为用户提供了一种在密钥被盗时恢复其帐户控制权的方法。帐户所有者可以通过使用过去 30 天内处于活跃状态的所有所有者密钥以及其指定的帐户恢复合作伙伴的批准重置其帐户中的所有者密钥。帐户恢复合作伙伴无法在没有所有者帮助的情况下重置帐户控制权。

此外，黑客即使尝试完成恢复过程，也无法获得任何收益，因为他们已经“控制”了帐户。如果黑客确实尝试重置权限，那么所有者指定的恢复合作伙伴可能会要求他提供更多的认证信息以及多重身份验证（电话和电子邮件）。通过这种方法很有可能会阻碍黑客行事或者让黑客在此过程中一无所获。

该过程也与简单的多签名约定非常不同。使用多签名事务，另一个实体成为每个事务执行的一方。相比之下，在恢复过程中，恢复合作伙伴只是恢复过程的一方，对日常交易没有任何权力。这大大减少了涉事方的成本和法律责任。

确定性并行执行

应用程序区块链共识取决于确定性（可重复）行为。这意味着所有并行执行不能使用互斥锁或其他锁原语。如果不使用锁机制，则必须有某种方法来保证可以并行执行的事务不会产生非确定性的结果。

2018 年 6 月发布的 EOS.IO 软件将以单线程运行，但它已经包含了支持未来将会使用的多线程和并行执行所需的数据结构。

在基于 EOS.IO 软件的区块链中，一旦启用并行操作，区块生成者就需要组织操作并将操作传递到各个独立的分片中，以便可以并行评估它们。时间表是区块生成器者的输出，并且将被确定性地执行，但是生成时间表的过程不需要是确定性的。这意味着区块生成者可以使用并行算法来调度事务。

并行执行的一部分意味着当脚本生成新的操作时不会立即将操作传递，而是会被计划到下一个周期中传递。无法立即传递的原因是因为接收方可能正在另一个分片中主动修改自己的状态。

最小化通信延迟

延迟是一个帐户将操作发送到另一个帐户然后收到响应所需的时间。最小化通信延迟的目的是使两个帐户能够在一个区块内相互交换操作，而不必在每个操作之间等待 0.5s。为此，EOS.IO 软件将每个块分为多个周期。每个循环分为多个分片，每个分片包含一个事务列表。每个事务都包含一组要传递的操作。该结构可以被视为树，其中交替的层被顺序地和并行地处理。

BlockRegionCycles(sequential) Shards(parallel) Transactions(sequential) Actions(sequential) Receiver and Notified Accounts(parallel)

在一个周期中生成的事务可以在任何后续周期或块中传递。区块生成者将继续向块添加循环，直到最大固定时间已过，或者没有新生成的事务要传递。

可以使用区块的静态分析来验证在给定周期内没有两个分片包含修改同一帐户的事务。因此只要维持该不变量，就可以通过并行运行所有分片来处理区块。

只读操作处理脚本

某些帐户可能能够在通过/失败的基础上处理操作而不修改其内部状态。如果是这种情况，那么这些处理脚本就可以并行执行，只要在特定周期内只有特定帐户的只读操作处理脚本包含在一个或多个分片中。

多帐户的原子交易

有时需要确保将动作原子地传递给多个帐户并被接收到。在这种情况下，两个操作都放在一个事务中，且两个帐户将被分配到相同的分片并顺序执行操作。

区块链状态的部分评估

区块链的扩展技术要求模块化的组件。不是所有人都要运行所有东西，特别是如果他们只需要使用应用程序一小部分功能时。

一个交易所应用程序开发人员运行完整节点，以便向其用户显示交易状态。此交易所应用程序不需要与社交媒体应用程序相关联的状态。EOS.IO 软件允许任何完整节点选择性地运行任何应用程序功能子集。如果你的应用程序并不依赖于另一个合约的状态，则传递给其他应用程序的操作将被安全地忽略。

主观尽力调度

EOS.IO 软件不能强制区生产者将任何操作传递给任何其他帐户。无论交易是由用户生成还是由智能合约自动生成，每个区块生成者对处理事务所需的计算复杂性和时间有自己的主观衡量。

在基于 EOS.IO 软件的运行中的区块链上，在网络级别，所有交易都根据执行的 WASM 指令的数量计量计算和带宽成本。然而，使用该软件的每个单独区块生产者可以使用他们自己的算法和度量来计算资源使用。当区块生成者断定事务或帐户消耗了不成比例的计算能力时，他们可以在自己生成区块时拒绝该事务; 但是，如果其他区块生产者认为该事务/账户是有效的则他们仍将处理该交易。

通常，只要一个区块生产者认为交易有效并且资源使用在可接受范围内限，那么所有其他区块生产者也将接受它，但是事务可能需要长达 1分钟 的时间才能找到这名生产者。

在某些情况下，生产者可能会创建一个包含超出可接受范围数量级事务的区块。在这种情况下，下一个块生产者可以选择拒绝该区块，并且该关系将被第三个生产者破坏。这与一个大型区块导致网络传播延迟时会发生的情况没什么不同。社区会注意到一种滥用模式，并最终将恶劣的生产者票选出局。

这种对计算成本的主观评估使得区块链不必精确和确定地测量某些东西运行的时间。通过这种设计，无需精确计算指令，从而在不破坏共识的情况下显着增加优化机会。

延期交易

EOS.IO 软件支持将交易延期到将来执行的交易类型，这使得计算能够移动到不同的分片和/或创建连续调度持续事务的长时间运行的进程。

上下文无关操作

上下文无关操作涉及的计算仅依赖于事务数据，而不依赖于区块链状态。例如，签名验证是仅需要交易数据和签名来确定签署交易的公钥的计算。这是区块链必须执行的最昂贵的单独计算之一，但由于此计算是无上下文的，因此可以并行执行。

上下文无关操作与其他用户操作类似，只是它们不需要访问区块链状态就可以执行验证。这不仅使 EOS.IO 能够并行处理所有无上下文操作，例如签名验证，更重要的是，这可以实现通用签名验证。

由于支持上下文无关操作，可扩展性技术（如 Sharding，Raiden，Plasma，State Channels 等）变得更加可并行化和实用化。这种开发实现了有效的区块链间通信和潜在的无限可扩展性。

Token 模型和资源使用

请注意：本白皮书中引用的密码学 TOKEN 指代的是那些已发布且使用 EOS.IO 软件的区块链。这些 TOKEN 并不指代那些在 ETHERUM 区块链中分发的与 EOS TOKEN 相关的兼容 ERC-20 标准的 TOKEN。

所有区块链都受资源限制，并且需要系统制止资源滥用的行为。在使用基于 EOS.IO 软件的区块链时，应用程序消耗了三类资源：

1. 带宽和日志存储(磁盘)
2. 计算和计算资源(CPU);
3. 状态存储(RAM);

带宽和计算资源又都分别由瞬时使用和长期使用组成。区块链维护所有操作的日志，并且该日志最终由所有完整节点存储和下载。通过操作日志，可以重建所有应用程序的状态。

计算债务指的是那些为了从日志中重新生成状态而必须执行的计算。如果计算债务增长太大，则有必要生成区块链状态的快照并丢弃区块链的历史记录。如果计算债务增长太快，那么可能就需要花费 6 个月的时间才能重播 1 年的交易记录。因此需要谨慎的管理计算债务。

区块链状态存储指的是那些可从应用程序逻辑访问的信息。它包括订单簿和帐户余额等信息。如果应用程序从未读取过该状态，则应用程序不应存储该状态。例如，博客文章内容和评论不是由应用程序逻辑读取的，因此它们不应存储在区块链的状态中。同时，帖子/评论的存在，投票数和其他属性则应该作为区块链状态的一部分由应用进行存储。

区块生成者发布其可用的带宽大小，计算能力和状态容量。EOS.IO 软件允许每个帐户消耗一定百分比的可用容量，该容量与该账户 3 天内资产合约中的持有的 Token 数量成正比。例如，如果启动了基于 EOS.IO 软件的区块链，并且一个帐户持有该区块链中可分配的总 Token 数量的 1% 的 Token，则该帐户有可以使用该区块链 1% 的状态存储容量。

因为带宽和计算资源时瞬态的，因此在已启动的区块链上采用 EOS.IO 软件意味着带宽和计算资源将被在部分储备资源中进行分配（不能保存未使用的容量以便未来使用）。EOS.IO 软件使用的算法类似于 Steem 用于限制带宽使用的算法。

客观和主观度量

如前所述，监测计算资源的使用对性能和优化有重大影响; 因此，对所有资源使用的约束最终都是主观的，区块生成者根据它们各自的算法和估计来执行约束。这些约束通常由区块生成器通过编写自定义插件来实现。

也就是说，某些琐碎的事情可以客观地衡量。交付操作的数量以及存储在内部数据库中的数据大小都可以很轻易地客观衡量。EOS.IO 软件允许区块生产者在这些客观测量上应用相同的算法，但可以选择在主观测量上应用更严格的主观算法。

接收方付费

企业需要支付办公空间，计算电力以及运营业务所需的其他成本。客户从企业手上购买特定产品，这些产品销售的收入将用于支付运营的业务成本。同样地，没有网站会要求访问者为访问其网站进行小额支付以便支付网站的托管费用。因此，分布式应用程序不应该强迫其客户在使用区块链的时候直接支付使用的费用。

已启动的基于 EOS.IO 软件的区块链不要求其用户为使用区块链直接支付费用，但不会限制或阻止企业为其产品确定营收策略。

虽然接收方确实可以付费，但 EOS.IO 使发送方能够为带宽，计算和存储付费。这使应用程序开发人员能够选择最适合其应用程序的付费方法。在许多情况下，发送方付款显着降低了那些不希望自己实现配给系统的应用程序的开发人员所面对的复杂性。应用程序开发人员可以将带宽和计算委派给用户，然后使用“发送方付费”模型保证使用。从最终用户的角度来看，它是免费的，但从区块链的角度来看，它是发送方付费的。

委派容量

在已发布的基于 EOS.IO 软件的区块链上的 Token 持有者，可能不会立即消耗全部或部分可用带宽，他们可以将这些未消耗的带宽委派或出租给其他人; 在这种运行 EOS.IO 软件的区块链上的区块生产者能识别这种容量分配并相应地分配带宽。

将交易成本与 Token 价格分离

EOS.IO 软件的主要优点之一是应用程序可用的带宽量完全独立于 Token 的价格。如果应用程序所有者在基于 EOS.IO 软件的区块链上持有一定数量的 Token，则应用程序可以在固定状态和带宽使用情况下无限期运行。在这种情况下，开发者和用户不会受到 Token 市场价格波动的影响，因此不依赖于价格反馈。换句话说，基于 EOS.IO 软件的区块链允许区块生成者能自然地增加每个 Token 可用的带宽，计算和存储，而与 Token 的价格无关。

基于 EOS.IO 软件的区块链也会在每次生成区块时授予区块生成者 Token。Token 的价格将影响生产者可以购买的带宽，存储和计算量; 此模型能够自动利用上涨的 Token 价格来提高网络性能。

状态存储成本

虽然可以委派带宽和计算，但应用程序状态的存储要求应用程序开发人员在删除被保留的状态之前保留 Token。如果状态永远不会被删除，那么 Token 就会被有效地从循环中移除。

区块奖励

基于 EOS.IO 软件的区块链将在每次生成区块的时向块区生产者授予新的 Token。在这些情况下，创建的 Token 数量会根据所有区块生产者发布的期望值的中位数确定。EOS.IO 软件可以配置为对生产者奖励实施上限，使得代币供应的年度总增长不超过5%。

工人提案系统

除了选举区块生产者之外，根据基于 EOS.IO 软件的区块链，Token 持有者可以选举出一定数量的旨在使社区受益的工人提案。获胜的提案将获得一个被设置好的 Token 通胀百分比减去已经支付给区块生产者的 Token。这些提案将收到与每个应用从 Token 持有人那里得到票数成比例的 Token，最多得到他们说明执行工作所需 Token 的数量。被选举提案会被 Token 持有人新选举出的提案代替。

实施工人提案系统的合同可能不会在 2018 年 6 月首次启动时到位，但资金机制将会在此时就绪。它将在区块生产者奖励开始的时候开始积累资金。由于工人提案系统将在 WASM 中实现，因此后续可以在不分叉的条件下添加到链中。

治理

治理指的是社区人员所处理的如下过程:

1. 就无法完全由软件算法解决的由于集体主观性导致的问题达成共识;
2. 实施达成的共识;
3. 通过宪法修正案改变治理规则本身;

基于 EOS.IO 软件的区块链实现了一个治理流程，可以有效地指导区块生成者的现有影响。由于缺乏明确的治理流程，先前的区块链通常依赖于临时的，非正式的，并且通常是有争议的治理流程，而这些流程会导致不可预测的结果。

基于 EOS.IO 软件的区块链知道权力是来源于将权力委托给区块生产者的 Token 持有者。区块生成者被授予有限和受监督的可以冻结帐户，更新有缺陷的应用程序，并建议对基础协议进行硬分叉更改的权限。

投票选举区块生成者被嵌入 EOS.IO 软件中。在对区块链进行任何更改之前，这些区块生产者必须批准它。如果区块生产者拒绝进行 Token 持有者所需的更改，则持有者可以将其投票出局。如果区块生成者在未经 Token 持有者许可的情况下进行更改，则所有其他非生产者全节点验证者（交易所等）将拒绝更改。

冻结账户

有时，智能合约会出现异常或不可预测的表现，并且无法按预期执行; 有时候，应用程序或帐户可能会发现一种使其能够消耗不合理的资源的漏洞。

当这些问题不可避免地发生时，区块生产者有权修复这种情况。所有区块链上的区块生产者都有权选择哪些交易包含在区块中，从而使他们能够冻结账户。基于 EOS.IO 软件的区块链通过将冻结帐户的过程置于活跃的生产者的 15/21 投票中来正式确定此行为。如果生产者滥用权力，他们可以被投票出局，并且被冻结的账户将被解冻。

更改帐户代码

当所有其他方法都失败并且“不可停止的应用程序”以不可预测的方式运作时，基于 EOS.IO 软件的区块链允许区块生成者在不硬分叉整个区块链的条件下替换帐户的代码。与冻结账户的过程类似，账户代码的替换行为需要通过活跃的区块生成者的 15/21 投票表决。

宪法

EOS.IO 软件使得区块链能够建立点对点服务协议或签署它的用户之间的约束性合约，这种类型的合约被称为“宪法”。宪法中的内容规定了用户之间不能完全由代码强制执行的义务，并通过建立管辖权和法律选择以及其他双方都接受的规则来帮助解决争议。每个在网络上被广播的交易都必须将宪法的散列值作为其签名的一部分，从而明确地将签名者绑定到合约中。

宪法还定义了源代码协议的可读性。这么做的用意是为了在错误发生时能识别错误和功能之间的差异，并指导社区如何进行正确的修复。

升级协议和宪法

EOS.IO 软件定义了基于官方源代码的协议以及宪法的升级过程：

1. 区块生产者提议修改宪法并通过 15/21 投票表决。
2. 区块生产者在连续的 30天 内保持 15/21 投票批准的新宪法。
3. 所有用户都必须表明接受新宪法作为未来交易处理的条件。
4. 区块生成者将宪法变化反映到源代码层面的，并使用新宪法的散列将其提交给区块链。
5. 区块生产者在连续的 30 天内保持 15/21 投票批准的新代码。
6. 对代码的更改将在 7天 后生效，在批准源代码后，所有非生产者完整节点将在 1周 内升级源代码。
7. 所有未升级到新代码的节点都会自动关闭。

默认情况下，配置 EOS.IO 软件，更新区块链以添加新功能的过程需要 2 到 3 个月，而修复非关键错误的不需要更改宪法的更新可能需要 1 到 2 个月。

紧急变更

如果需要修改软件中会伤害到用户权益的有害的错误或安全漏洞，那么区块生产者可以会加快上述流程。一般来说，为了引入新功能或修复无害错误而加速更新进程是违反宪法的。

脚本和虚拟机

EOS.IO 软件首先是一个协调向帐户传递经过身份验证的消息（称为操作）的平台。脚本语言和虚拟机的细节特定于其实现细节，这些细节大部分独立于 EOS.IO 技术的设计。任何具有足够性能的并且具有确定性以及完备沙盒功能的语言或虚拟机都可以与 EOS.IO 软件 API 集成。

基于模式定义的操作

帐户之间发送的所有操作都通过模式进行定义，该模式是区块链共识状态的一部分。此模式允许操作在二进制和 JSON 表示之间进行无缝转换。

基于模式定义的数据库

EOS.IO 同样使用与操作类似的模式定义数据库状态。这可确保所有应用程序存储的所有数据都可被解析为人类可读 JSON 的格式，但以二进制的形式进行高效地存储和操作。

通用多索引数据库接口

开发智能合约需要定义好的数据库模式以便跟踪，存储和查找数据。开发人员通常需要对同一数据的多个字段进行排序或索引，并保持所有索引之间的一致性。

从应用程序中分离身份验证

为了最大化可并行执行的机会并最小化与从事务日志重新生成应用程序状态相关的计算负担，EOS.IO 软件将验证逻辑分为三个部分：

1. 验证操作是内部一致的;
2. 验证所有前提条件是否有效;
3. 修改应用程序状态.

验证操作的内部一致性是只读的，不需要访问区块链状态。这意味着它可以以最大程度地并行执行。验证前提条件（例如所需的带宽）是只读的，因此也可以从并行执行中受益。只有修改应用程序状态需要写权限，并且必须按顺序处理每个应用程序。

身份验证是验证操作是否可以执行的只读过程。实际上由应用程序进行处理。实时地，需要执行两个计算，但是一旦事务被包括在区块链中，则不再需要执行认证操作。

区块链间通信

EOS.IO 软件旨在促进区块链间通信。这是通过简单地证明操作存在和操作序列实现的。这些证明与围绕操作传递设计的应用程序架构相结合，可以隐藏应用程序开发人员之间的区块链间通信和证明验证的细节，从而可以向开发人员提供更高级别的抽象接口。

轻客户端的 Merkle 证明(LCV)

如果客户端不需要处理所有事务，则与其他区块链集成会更容易。毕竟，交易所关心的只是进出交易所的转移量而已。理想的选择是交易链能够利用轻量级的存在证明而不必完全信任他的区块生产者。至少区块链的区块生产者希望使用最小的开销与另一个区块链同步。

LCV 的目标是能够生成相对轻量的存在证明，这可以由记录相对轻量级数据集的任何人进行验证。在这种情况下，目标是证明特定事务包含在特定块中，并且该块包含在特定区块链的验证历史中。

比特币通过假设所有节点都可以访问区块头每年最大 4MB 的完整历史记录以支持事务验证。比特币每秒能处理 10 个事务，有效的证明需要大约 512字节 的空间。对于具有 10分钟 区块间隔的比特币区块链而言这是适用的，但对于具有 0.5秒 区块间隔的基于 EOS.IO 的区块链来说这就不再是轻量的操作了。

EOS.IO 软件为在包含交易的时间点之后的具有任何不可逆区块头的任何人提供轻量级证明方法。通过使用散列链接结构可以证明任何具有小于 1024字节 大小的证明的事务的存在。

给定区块链中任何区块的 id，并且该区块头中显示该区块是可信且不可逆的。就可以证明该区块包含在区块链中。该证明采用 ceil(log2(N)) 摘要作为其路径，其中 N 是链中的区块数。通过一个 SHA256 的摘要，就可以证明包含 1亿个 864字节 的区块的区块链中存在任何区块。

通过正确的散列链接生成区块以实现这些证明几乎没有额外的开销，这意味着没有理由不以这种方式生成区块。

当需要验证其他链上的存在证明时，可以进行各种各样的时间/空间/带宽优化。跟踪所有区块头(420 MB/年)能保持使证明所需存储空间尽可能小。仅跟踪最近的区块头可以在最小长期存储空间和存在证明所用大小之间进行权衡。或者，区块链可以使用惰性评估方法使用，这种评估方法要求区块链记住过去证明过程中的中间哈希值。新证明只需要包含已知稀疏树的链接。具体使用什么方法取决于包含由 merkle 证明引用的交易的外部区块的百分比。

在具有一定密度的互连性之后，能够高效的简化让一个链包含另一个链的整个区块交易历史的难度，并且消除所需的证明。出于对性能的考虑，最好减少区块间的证明。

链间通信的延迟

当与另一个外部区块链进行通信时，区块生成者必须等到 100% 确定另一个区块链中的某个事务已被另一个区块链不可逆地确认后才可以将该事务作为有效输入。使用基于 EOS.IO 软件并且配备每 0.5 秒生成一个区块的 DPOS 共识机制以及增加拜占庭容错不可逆性的区块链大约需要 0.5 秒才能接收该事务。如果任何链的区块生产者没有等待不可逆转性确认完成，那就像是一个交易所记入了一笔后来被撤销的存款，这种行为可能会影响区块链共识的有效性。EOS.IO 软件使用 DPOS 和 aBFT 提供快速的不可逆性确认。

完整性证明

当使用来自区块链外的 merkle 证明时，知道所有处理的事务都是有效的和知道没有跳过或省略任何事务之间存在着明显的区别。虽然不可能证明所有最近的交易都是已知的，但可以证明交易历史中没有间隙。EOS.IO 软件通过为每个帐户的每个操作分配特定序号来实现此目的。用户可以使用这些序号来证明所有针对特定帐户的操作已经处理过，并且它们是按顺序进行处理的。

隔离见证

隔离见证(SegWit)的概念是，在交易不可变的被包含在区块链中之后，交易签名和交易就不再相关。一旦交易不可变，就可以修剪签名数据，但其他人仍然可以获得当前状态。在大多数事务中有很大比例的数据是签名数据，因此隔离见证可显着节省磁盘使用和同步时间。

同样的概念可以应用于区块链间通信的 merkle 证明。一旦证明被接受并且不可逆的被记录到区块链中，就不再需要通过证明使用的 2KB SHA256 哈希值来获得正确的区块链状态。在区块链间通信的情况下，使用这种方式比保留签名节省 32 倍的资源。

隔离见证的另一个例子是 Steem 的博客文章。在此模型下，帖子仅包含 SHA256(以及博客内容)，博客内容将包含在隔离的见证数据中。区块生成者将验证内容是否存在并具有给定的散列值，但是不需要存储博客内容就能从区块链日志中恢复当前状态。这使得能在不必永久存储所有内容的情况下证明内容曾经是已知的。

结论

EOS.IO 软件是根据经过验证的概念和最佳实践的经验设计的，代表了区块链技术的基本进步。该软件是全球可扩展区块链社会的整体蓝图的一部分，其中分布式应用程序可以轻松地部署和管理。